2023-11-03
I looked more closely at Osterhout. I like a lot of what he’s going for, and I think it can deliver the earliest version of software quickly and well.
However, I think it creates an elevated risk of the system devolving. He is also very cavalier about dismissing other schools of thought. His discussion of testing is just two pages long, in a chapter called “Software Trends” (suggesting that testing is a “trend”).
In it, he writes off test-driven development because it’s too focused on implementation to discover good designs. On the contrary, outside-in TDD forces you to articulate your thinking from the highest level (product requirements) to the lowest (individual operations). The best tools I’ve found for building maintainable code start with robust test suites based on a hierarchy of responsibilities.
I think the real reason he doesn’t like TDD is that the concept of deep classes is in tension with a hierarchy of responsibilities. I think there’s good reasons to build software the way that he describes. And I also think there are a number of ways to build good software, all of which boil down to a disciplined approach to the addition and modification of functionality. His is certainly one of them. But I worry that preaching deep classes and systematic use of comments will cause lazy, rushed engineers to revert to building untestable ‘everything classes’ with comments that quickly go out of date.
To be clear, I know that’s not what he’s saying they should do. Not at all! But I do think it’s more likely to end up what they do, then if they are asked to factor everything to single responsibilities.
He mentions that he has written 250,000 lines of code working with a variety of teams. This suggests that he is never with a team for very long. The strategy he describes will produce a lot of functionality in a short time, as will vertically integrated frameworks like Django and Ruby on Rails. I shy away from tools like those, as I do from a philosophy like his, for one simple reason: although these systems can be maintainable with strict discipline, the default will be a devolution to a state of unmaintainability.
My approach definitely ships the first production-grade version of software much more slowly. (I write spikes/POCs in a manner similar to what he describes.) Whether that’s good or not, and whether it pays off in the long run, is something we’ll just have to wait and see…